refs: RUM-17370

ARM64 has a security feature called Pointer Authentication Codes (PAC),
where the CPU cryptographically signs address values, encoding the
signature in the upper bits of the 64-bit value. It can then verify
these addresses before jumping to them, to detect stack manipulation
etc. at the hardware level.

The SDK's in-process crash handler for POSIX reads return addresses as
it walks the stack frame. When running arm64 Linux builds in Docker, I
noticed that these addresses weren't being correctly resolved to loaded
modules for shared libraries.

As it turns out, module resolution was failing because the upper bits
were set by PAC, causing the resolved address to land outside the load
range of the module.

When compiled for ARMv8.3-a or later (__ARM_FEATURE_PAUTH), we use the
xpaci instruction to strip PAC bits. This asks the hardware to remove
exactly the signature bits using its own key and VA-width configuration,
which is correct on kernels with 52-bit user VAs (CONFIG_ARM64_VA_BITS_52)
where bits [51:48] are legitimate address bits that a hard-coded 48-bit
mask would incorrectly zero. On ARMv8.0-8.2 hardware (no PAC, no 52-bit
VA support), we fall back to masking the lower 48 bits.

The previous approach guarded xpaci behind __ARM_FEATURE_PAUTH and fell
back to a hard-coded 48-bit mask when the flag was absent. That flag is
only defined when the compiler is invoked with -march=armv8.3-a or later,
so on a generic arm64 build the mask would fire even on PAC-capable
hardware — incorrectly zeroing bits [51:48] on kernels configured for
52-bit user VAs (CONFIG_ARM64_VA_BITS_52).

xpaci is the right tool unconditionally: it asks the CPU to strip exactly
the PAC bits using its own key and VA-width configuration, so it handles
any VA width correctly. On pre-PAC hardware (ARMv8.0-8.2) it falls in
the HINT space and executes as a NOP, which is also correct since those
CPUs never encode PAC bits in addresses. Clang's integrated assembler
accepts the instruction regardless of -march, so no compile-time feature
guard is needed.

Clang's assembler rejects 'xpaci' unless the target architecture includes
the pauth feature (i.e. -march=armv8.3-a or later). Without an explicit
-march flag, aarch64-linux-gnu builds default to armv8-a and fail to
compile the inline asm, even though the instruction is safe to run on all
AArch64 hardware.

Fix this by pinning the operand to x16 and emitting the instruction via
.inst 0xDAC143F0 (the fixed encoding for xpaci x16). The assembler emits
the bytes directly without needing to know about pauth. x16 (IP0) is a
caller-saved scratch register that is safe to use in a signal handler.

The CI Linux jobs all run on amd64 runners so the aarch64 code path is
never compiled there; this would only be caught by a customer building
natively or cross-compiling for arm64 Linux.